來說說為什麼我會選擇這個題目。

記得 2023 剛轉職的那年，有機會參與了 WebConf。
其中一個主題："鳳‧極意？！ - Paul Li" ，都讓我印象深刻。
從精美的簡報到介紹的內容，都讓我驚艷不已。也在當下了解到，原來原生的元件也能如此的好用。

同時，Paul 在簡報中多次提到了 Web Component 這個名詞，而這個名詞對於當時才剛入職半年的我來說，是個相當陌生的名詞。
當下雖然有大略查了一下資料，也大致看了一些語法範例，但說實話，並沒有真正理解它的用途與價值。就這樣，Web Component 成為了我記憶中「看過，但還不懂」的技術之一。

時間也就這樣子過了一年，2024 年，我再次參加了 WebConf。
在一場演講中，主講人奶綠茶隨口提到：「有些元件我們公司會使用 Web Component 來做...」，雖然當下並沒有多做解釋，但這句話也重新喚起了我對這項技術的注意。

讓我當下開始思考：Web Component 是不是其實真的很好用？不然為什麼這些業界前輩會一再提起它？它到底可以為專案帶來什麼實際效益？又有哪些元件，真的適合用它來實作？

當天 Conf 結束後也開始初步探索這個技術的基礎知識，但事情不是憨人想的那麼簡單，只做了幾個小元件，三分鐘熱度的我，又將這件事拋到腦後了...

現在回頭看，入職已經兩年多，實務上常會遇到一些需求重複的 UI 元件，例如按鈕、表單欄位、提示框等，雖然功能不難，但在不同專案中常需要反覆調整、重寫。
這讓我開始認真思考，有沒有可能透過某種技術，把這些元件封裝得更獨立、可攜，甚至跨專案共用？

這樣的需求，似乎正是 Web Component 想解決的問題。
所以我決定用這 30 天的時間，好好的深入了解 Web Component，也希望可以對大家有幫助。

這裡也小小提醒一下，這整個系列內容會需要基礎的前端知識：

1. 對 DOM 元素有基本理解
2. 對 JavaScript 的語法有基本理解
3. 對 Class 有概念
4. 知道什麼是 this
5. 知道怎麼用原生的 JavaScript 選取 DOM 元素